\section{Event Driven Programming}

	\textit{Event driven programming} (EDP) is a type of programming that lets the programmer specify reactions to certain activities. Activities in this case would be mouse actions, keyboard actions or any form of interaction. These activities are more commonly refered to as \textit{Events}.
	
	Event driven programming is most commonly used in \textit{Graphical User Interfaces} (GUIs). It is commonly implemented as a loop which waits for an event to occur and then processes the event as it occurs. An event stream queue is used for queueing the events as they come in.
	
	\subsection{Observer Pattern}
	
		Figure \ref{fig:designpatternevent} shows the observer design pattern for the event handler.
		
		\begin{figure}[h!]
			\begin{center}
				\includegraphics[width=0.55\textwidth]{./FutureWork/EventBasedProgramming.pdf}
			\end{center}
			\caption{The observer design pattern for implementing event driven programming}
			\label{fig:designpatternevent}
		\end{figure}
		
		The figure shows a stream of events which are handled by the dispatcher. The dispatcher analyses each event to determine which handler belongs to each particular event. If a dispatcher can not find a fitting handler there are two options which can be implemented. The handler can either discard the event, or it can throw an exception to enable the programmer to handle the problem. When implementing this design there has to be implemented a special handler to handle an end of event stream, which would indicate that the handler is waiting for input.
		
		\begin{lstlisting}[basicstyle=\small\sffamily, 
					keywords={do, forever, event, if, else},
					keywordstyle={\color{blue}},
					comment={[l]{//}}, morecomment={[s]{/*}{*/}}, commentstyle=\itshape,
					columns={[l]flexible}, numbers=left, numberstyle=\tiny,
					frameround=fftt, frame=shadowbox, captionpos=b,]	
		do forever()
		{
			//setting the event to analyze the type
			event = get.eventfromstream();
			
			//Checking the types as follows.
			if(event.typeof()==EndOfEventStream);
				break;
				
			if(event.typeof() == ...)
				//function to be executed goes here
			else
				//handle event types which are not implemented
		}
		\end{lstlisting}
		
	\subsection{EDP Implementation}

	To alter CLUBs to use event driven programming the interpreter would need to include an event handler, and functionality to store user created events.
	Figure \ref{fig:clubs_eventbased} shows a possible architecture for an event driven interpreter working with a user interface. 
	
	\begin{figure}[h!t]
		\begin{center}
		\includegraphics[width=\textwidth]{./FutureWork/EDPCLUBs.pdf}
		\end{center}
		\caption{Architecture for event driven interpreter}
		\label{fig:clubs_eventbased}
	\end{figure}
	
	The interpreter builds the elements and events from the CLUBs code, then constructs the GUI from the elements. The user playing the game causes events through the GUI, which are sent to the event handler and fetched from the interpreter.


		

\section{Event Declaration}

As described in the problem domain chapter under section \ref{sec:flow}, board games have two sets of events:

\begin{itemize}
	\item{Static Events}
	\item{Dynamic Events}
\end{itemize}

Where static events are universal events that occur in all board games regardless of user interaction, and dynamic events always occur in response to user actions.

As static events are not part of defining a boardgame, the programmer would not need to alter them. For this reason we focus on the creation of \textit{dynamic} events; events in response to actions. 

An event is a control structure composed of three parts:

\paragraph{Trigger} The action the event is responding to.

\paragraph{Condition} The conditions that must be met for the event to activate.

\paragraph{Effect} The body of the event, essentially the method executed.

Custom events would automatically exist in response to custom actions, which can be freely defined.


\subsection{Actions}			
			
In CLUBs, actions contain their own functionality, but this would not be consistent with an event driven paradigm. As described in section \ref{sec:actions_and_effects} actions simply cause effects, so the expression of their effects could instead be expressed as events occuring in response to the actions. By moving conditions and effects away from actions the architecture of board games becomes implicit in the language, thus removing unnecessary complexity. 

 Through the interface the player can activate actions that are included in their turn, but they can also be triggered through events. For example, a move action can be defined as a remove action followed by a place action.

\subsection{Conditions}

When an action is activated, the effects are not immediatly applied to the game. Before an action's effect applies to the game it must pass a condition. For example, a player attempting to move a piece will not have any effect if the piece does not belong to the right player, and a piece will not move to a field that does not satisfy the condition for the target field, such as being reachable from the starting point by two left steps.

	\subsection{Benefit for the Programmer}
	
	Currently expressing a rule in CLUB's has to done inside the main loop, requiring an understanding of the interpreter's architecture. It also means that code becomes increasingly complicated when more rules are introduced, causing readability to suffer. 
	
	As an example, this pseudocode expresses the rule of chess where a piece occupying a field is removed when an opponent enters the cell in CLUBs:
	\begin{lstlisting}[basicstyle=\small\sffamily, 
				keywords={do, event, if, else, Clear},
				keywordstyle={\color{blue}},
				comment={[l]{//}}, morecomment={[s]{/*}{*/}}, commentstyle=\itshape,
				columns={[l]flexible}, numbers=left, numberstyle=\tiny,
				frameround=fftt, frame=shadowbox, captionpos=b,]	
//after selecting a cell to move to
if (cell is occupied)
{
	Clear the cell;
}
//additional code after removing the defending piece
	\end{lstlisting}
	
	Note that the rule is stated as part of the movement function, making it difficult to determine what code belongs to which rule. Here is the same rule expressed with EDP:
	
		\begin{lstlisting}
//placed anywhere in event definitions

on Colission remove Defender;
		
	\end{lstlisting}
	
	\textit{Colission} would be an event, predefined as when a piece enters a cell that has another piece in it. The \textit{Colission} event stores references to the pieces \textit{Attacker} for the entering piece and \textit{Defender} for the piece allready in the field, as well as a reference to the cell in which the colission occurs.

	The implementation of the rule is much closer to the rule as it is expressed in the game, enhancing both readability and writeability.
	
	By limiting where the programmer is allowed to change the program state they are no longer tasked with building an architecture for their program, thus removing potential errors, improving readability by organizing rules explicitly and speeding up development.
	
	\section{Board Representation}


In our process we considered two approaches to representing boards:

\begin{itemize}
\item{two-dimensional array structure}
	\item{directed graph structure}
\end{itemize}

With a two-dimensional array square boards are easily represented by a set of X and Y coordinates, however asymmetric boards or branching paths are very difficult to express, as they are not necessarily limited to 4 connected cells, nor are the cells necessarily identical in shape or size.

One-way directional paths can easily be represented in a two-dimensional array, but result in complicated movement conditions, as pieces can move in different directions depending on where in the path they are.

			\begin{figure}[h!t]
				\begin{center}
				\includegraphics[width=\textwidth]{./FutureWork/board1.pdf}
				\end{center}
				\caption{Boards defined via arrays}
				\label{fig:arrayboard}
			\end{figure}


Expressing a two-dimensional array structure is very straightforward, as all that is needed is the width and height. Each cell can be referred to by their coordinates, giving immediate access to all cells.

By contrast a directed graph structure would be able to express any board, of any shape and dimension, but forfeits direct access to specific cells as they would not be accessible through their coordinates. A support structure, like numbering and linking to each cell could be used to provide this feature, but creating a cogent numbering system for multiple connected areas would be difficult.


			\begin{figure}[h!t]
				\begin{center}
				\includegraphics[width=\textwidth]{./FutureWork/board2.pdf}
				\end{center}
				\caption{Boards defined via directed graphs}
				\label{fig:dag} 
			\end{figure}

\subsection{Movement Definition}

For path-based boards directed graphs offer immediate benefits by allowing each cell to refer to a ``next'' cell, making it much easier to establish rules of movement than the array structure, as the pieces are simply allowed to use the edges labeled ``next''. When expressing movement for a non-linear path in a two dimensional array the movement is dependant on your current position. As a result it would be necessary to implement the functionality of a directed graph, which is assumed to be beyond the abilities of our demographic.

The problem with directed graphs is representing them visually, as not all boards have uniform fields. This could be accomodated by simply assigning each field a set of coordinates, and selecting a background image to draw the board. Unfortunately this would place a lot of extra work on the programmer as they would have to fill in a lot of coordinates. It would also require an image of the board, but at the prototyping stage this can be assumed finished.

The most effective solution would be a GUI that allows the programmer to simply ``paint'' the board using fields and connections instead of defining the boards in code, however the implementation of this is outside our scope.
	
	
\section{Conclusion on Future Works}

As discussed in this chapter, implementing event driven programming into CLUBs would cause the code to closer reflect the rules expressed in the board game. It would also provide a rigid architecture, thereby avoiding potential errors by the programmers and help preserve overview by organizing the rules explicitly.

By switching to directed graphs for the representation of boards we would be able to represent all possible board configurations, although expressing this through code would be impractical due to complications in the visual representation. Directed graphs would also help simplify movement definitions, especially for boards where movement is not uniform.

However, implementing these changes would require us to change a lot in the EBNF, as events would overtake the purpose of actions as they exist now. Furthermore, the interpreter implementation would need radical changes.
